Real time communications of musical tone information

ABSTRACT

A musical tone data communications system having a unit for generating MIDI data of a musical performance by a player, a unit for transmitting the generated MIDI data over a communications network and a unit for receiving the transmitted MIDI data and reproducing musical tones corresponding to the MIDI data in real time.

[0001] This application is based on Japanese Patent Applications No.8-349939 filed on Dec. 27, 1996 and No. 9-059600 filed on Mar. 13, 1997,the entire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention relates to data communicationstechnologies, and more particularly to real time data communicationstechnologies. A “real time” response to an event is essentiallysimultaneous with the event itself. However, in communications, becauseof time delay for transmission time, signal synchronization, othernecessary signal process or the like, “real time” does not mean strictlysimultaneous.

[0004] 2. Description of the Related Art

[0005] As a standard specification for communications between electronicmusical instruments, a music instrumental digital interface (MIDI)specification is known. Electronic musical instruments equipped withinterfaces of the MIDI specification can communicate with each other bytransferring MIDI data via a MIDI cable.

[0006] For example, an electronic musical instrument transmits MIDI dataof a musical performance by a player, and another musical instrumentreceives it to reproduce it. As one electronic musical instrument isplayed, another electronic musical instrument can be played in realtime.

[0007] In a communications network interconnecting a plurality ofgeneral computers, various types of data are transferred. For example,live musical tone data or other MIDI data can be transmitted from onecomputer, which once stored the data in its storage device such as ahard disk, via the communications network to another computer whichstores the received data in its storage device. A general communicationsnetwork is, however, configured to perform only general datacommunications, and is not configured to properly process MIDI data.

[0008] Specifically, although the MIDI specification allows the “realtime” communications to be performed between electronic musicalinstruments, it is not suitable for long distance communications andcommunications via a number of nodes. The general communications networkis essentially configured to provide services of long distancecommunications and multiple-node communications, but it does not takeaccount of “real time” communications between electronic musicalinstruments.

[0009] Real time communications of musical information uses a largeamount of information per unit time, and the traffic of thecommunications line becomes heavy. As compared to point-to-pointcommunications, point-to-multipoint communications of musical tone datais more likely to make the traffic of communications lines heavy. Theheavy traffic of communications lines generates a transmission delay andhinders a real time musical performance.

SUMMARY OF THE INVENTION

[0010] It is an object of the present invention to provide technologiesof musical tone data communications capable of a real time musicalperformance at multiple nodes.

[0011] It is another object of the present invention to providetechnologies of data communications capable of avoiding a heavy trafficof communications lines.

[0012] According to one aspect of the present invention, there isprovided a musical tone data communications system, comprising:transmitting means for transmitting inputted MIDI data in real time overa communication network.

[0013] According to another aspect of the present invention, there isprovided a data communications system comprising: receiving means forreceiving data; access checking means for checking the number ofcommunications lines accessed externally; and transmitting means capableof reducing the amount of data received by the receiving means inaccordance with the number of communications lines accessed externally,and transmitting the reduced data to the communications lines accessedexternally.

[0014] If the number of accessed communications lines is large, theamount of received data is reduced to thereby alleviate the trafficcongestion, whereas if the number of accessed communications lines issmall, it is not always necessary to reduce the data amount.

[0015] According to a further aspect of the present invention, there isprovided a communication system having a plurality of communicationsapparatuses each having receiving means and transmitting means, wherein:the receiving means of the plurality of communications apparatusesreceive the same data; the transmitting means of the plurality ofcommunications apparatuses can reduce the amount of data received by thereceiving means and can transmit the reduced data; and the data reducedby one of the communications apparatuses is different from the datareduced by another of the communications apparatuses.

[0016] Since the data reduced by one and another of communicationsapparatuses is different, the quality of data transmitted from eachcommunication apparatus is different. For example, the type or reductionfactor of the reduced data may be made different at each communicationapparatus. Therefore, a user can obtain data of a desired quality byaccessing a proper communication apparatus.

[0017] According to still another aspect of the invention, there isprovided a musical tone data communications method comprising the stepsof: (a) transmitting MIDI data over a communications network; and (b)receiving the transmitted MIDI data and supplying the received MIDI datato a tone generator in real time.

[0018] MIDI data can be transmitted to a number of nodes by using acommunications network. At each node, the MIDI data is reproduced inreal time to generate musical tones.

[0019] According to still another aspect of the invention, there isprovided a musical tone data communications method comprising the stepsof: (a) transmitting MIDI data; and (b) transmitting recovery data afterthe MIDI data is transmitted, the recovery data indicating acontinuation of transmission of the MIDI data.

[0020] If there is no communications error, transmitted MIDI data can becorrectly received at a partner communications apparatus. If there is acommunications error, transmitted MIDI data cannot be correctly receivedat a partner communications apparatus. Even in such a case, thecommunication error can be remedied by transmitting the recovery data.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021]FIG. 1 is a schematic diagram showing a musical tone datacommunications network.

[0022]FIG. 2 is a block diagram showing the hardware structure of anencoder and a home computer.

[0023]FIG. 3 is a timing chart illustrating a method of dealing withMIDI data communications errors.

[0024]FIG. 4 shows the format of a communications packet.

[0025]FIG. 5 is a flow chart illustrating the operation of atransmission process to be performed by an encoder.

[0026]FIGS. 6A and 6B are flow charts illustrating the operation of aninterrupt process to be performed by the encoder, the flow chart of FIG.6A illustrating a transmission process of recovery key data and the flowchart of FIG. 6B illustrating a transmission process of recovery tonegenerator setting data.

[0027]FIG. 7 is a flow chart illustrating the operation of a receptionprocess to be performed by a home computer.

[0028]FIG. 8 is a flow chart illustrating the details of an eventprocess at Step SD6 of FIG. 7.

[0029]FIG. 9 is a flow chart illustrating the operation of an interruptprocess to be performed by a home computer.

[0030]FIG. 10 is a diagram showing the structure of a memory of aproxity server.

[0031]FIG. 11 is a graph showing the relationship between the number ofaccesses and a thinning index.

[0032]FIG. 12 is a flow chart illustrating the operation of a process tobe performed by a proxity server when a user accesses the proxityserver.

[0033]FIG. 13 is a flow chart illustrating the operation of a process tobe performed by a proxity server when a user releases an access to theproxity server.

[0034]FIG. 14 is a flow chart illustrating the operation of a process tobe performed by a proxity server when it receives data from a mainserver.

[0035]FIG. 15 is a flow chart illustrating the operation of a process tobe performed by a proxity server when it thins recovery data.

[0036]FIG. 16 is a flow chart illustrating the operation of a process tobe performed by a proxity server when it preferentially transmitskey-off event data.

[0037]FIG. 17 is a flow chart illustrating the operation of a process tobe performed by a proxity server when it transfers data by deletingimage data.

[0038]FIG. 18 is a flow chart illustrating the operation of a process tobe performed by a proxity server when it transfers data by lowering aresolution of the data.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0039]FIG. 1 shows a musical tone data communications network.

[0040] A concert hall 1 is installed with a MIDI musical instrument 2, acamera 4, encoders 3 and 5, and a rooter 6. A player plays the MIDImusical instrument 2 in the concert hall 1. The MIDI musical instrument2 is an electronic musical instrument having a MIDI interface, generatesMIDI data in real time in accordance with the performance by a player,and supplies it to the encoder 3. The encoder 3 transmits each packet ofMIDI data of a predetermined format in real time to the Internet via therooter 6. The data format will be later described with reference to FIG.4.

[0041] The camera 4 takes an image of a player and supplies it as imagedata to the encoder 5. The encoder 5 transmits each packet of image dataof a predetermined format to the Internet via the rooter 6. A microphone13 samples sounds of a vocal (voice data), an acoustic musicalinstrument (for example a piano), or an electric musical instrument, andsupplies these sample data to an encoder 14 as sound data. The encoder14 transmits each packet of sound data of a predetermined format to theInternet via the rooter 6. The data format will be later described withreference to FIG. 4.

[0042] The rooter 6 transmits MIDI data and image data to the Internetto be described hereinunder. The data is supplied from the rooter 6 to amain server 7 via a public telephone line or a leased telephone line,and to a plurality of proxity servers 12 a, 12 bj, 12 c, . . . andfarther to a world wide web (WWW) server 8 which is called a provider.

[0043] The proxity servers 12 a, 12 b, 12 c, . . . are hereinaftercalled a proxity server 12 singularly or collectively. The proxityserver 12 functions to avoid the traffic congestion of communicationslines. The proxity server 12 controls the amount of data supplied fromthe main server 7 in accordance with the traffic conditions ofcommunications lines and supplies the reduced data to the WWW server 8.For example, if the number of users (lines) is large, it is judged thatthe communications lines are congested, and the data is thinned toreduce the data amount and avoid the traffic congestion.

[0044] A plurality of proxity servers 12 a, 12 b, 12 c, . . . may havedifferent data reduction amounts or different data reducing methods. Thedata reduction amount influences the sound and image qualities. Thelarger the data reduction amount, the lower the sound and imagequalities.

[0045] Fog example, the proxity server 12 a may limit the number ofaccessible users to improve the sound and image qualities, whereasanother proxity server 12 c may lower the sound and image qualities toincrease the number of accessible users. Such a function of the proxityserver 12 can alleviate the traffic congestion of communications lines.

[0046] A user can access the Internet by connecting its home computer 9to the WWW server 8 to receive MIDI data and image data in real time.The term “home computer” used herein is intended to mean any computerused for “home” concert as opposed to a remote concert hall. The homecomputer 9 has a display device for the display of image data and anexternal or built-in MIDI tone generator (sound source) for thegeneration of musical tone signals. The MIDI tone generator generatesmusical tone signals in accordance with MIDI data, and supplies the tonesignals to a sound output device 11. The sound output device 11 has aD/A converter, an amplifier and a speaker to reproduce sounds inaccordance with the supplied tone signals. Sound data is reproduced,converted from an analog form to an digital form, amplified by anamplifier, and reproduced as sounds from a speaker. Sounds same as thoseproduced in the concert hall 1 can be reproduced from the sound outputdevice 11 in real time.

[0047] If an external MIDI tone generator 10 is used, the home computer9 makes the MIDI generator 10 generate musical tone signals and thesound output device 11 reproduce sounds.

[0048] Since the MIDI data and sound data are more important for a userthan image data, the MIDI data and sound data are processed with apriority over the image data. Although a user does not feel uneasy aboutthe image data with poor image quality and smaller frame number, soundinformation and musical tone information of MIDI data is required tohave a high quality.

[0049] Any user can listen to a musical performance in real time byconnecting the home computer 9 to the Internet while looking at eachscene of the concert hall 1 on the display device at home without goingto the concert hall 1. A number of users can enjoy at home the musicalperformance played in the remote concert hall. MIDI data is transmittedfrom the concert hall 1 to each user so that each user can share asituation of the concert hall 1 as if the player is playing theelectronic musical instrument at user home.

[0050] The promoter of a concert determines a prescribed number of theconcert and sells tickets to users. Tickets may have ranks such as rankA (special seat), rank B (ordinary seat) and rank C (gallery). Forexample, a user with a rank A ticket can access the proxity server 12 afor the reception of high quality sound and image information, a userwith a rank B ticket can access the proxity server 12 b for thereception of sound and image information with a reduced data amount, anda user with a rank C ticket can access the proxity server 12 c for thereception of only sound information with a reduced data amount.

[0051] Since not live musical tone information but MIDI data istransmitted over the Internet, the sound quality is not degraded bynoises. However, since long distance communications via a number ofcommunications sites is performed over the Internet, the followingmethod of dealing with communications errors becomes necessary when datais transmitted from the encoders 3 and 5 and when the data is receivedat the home computer 9. For example, communications errors include datachange, data loss, data duplication, data sequence change and the like.

[0052]FIG. 2 shows the hardware structure of the encoders 3 and 5 andthe home computer 9 which may be a general computer. Connected to a bus31 are an input device 26 such as a keyboard and a mouse, a displaydevice 27, a MIDI tone generator 28, a communications interface 29 forconnection to the Internet, a MIDI interface 30, a RAM 21, a ROM 22, aCPU 23, and an external storage device 25.

[0053] Various instructions can be entered from the input device 26. Inthe home computer 9, the display device 27 displays each scene of aconcert hall, and the MIDI tone generator 28 generates musical tonesignals in accordance with received MIDI data and transmits them to anexternal circuitry.

[0054] The communications interface 29 is used for transferring MIDIdata and image data to and from the Internet. The MIDI interface 30 isused for transferring MIDI data to and from an external circuitry.

[0055] The external storage device 25 may be a hard disk drive, a floppydisk drive, a CD-ROM drive, a magneto-optical disk drive or the like andmay store therein MIDI data, image data, computer programs and the like.

[0056] ROM 22 may store therein computer programs, various parametersand the like. RAM 21 has a key-on buffer 21 a and a tone generatorsetting buffer 21 b. The key-on buffer 21 a stores a key-on eventcontained in MIDI data, and the tone generator setting buffer 21 bstores tone generator setting data contained in MIDI data.

[0057] RAM 21 has also working areas such as buffers and registers tocopy and store data in ROM 22 and the external storage device 25. Inaccordance with computer programs stored in ROM 22 or RAM 21, CPU 23performs various calculations and signal processing. CPU 23 can fetchtiming information from a timer 24.

[0058] The external storage device 25 may be a hard disk drive (HDD).HDD 25 may store therein various data such as application program dataand MIDI data. If a necessary application program is stored not in ROM22 but in a hard disk loaded in HDD 25, this program is read into RAM 21so that CPU 23 can run this application program in the similar manner asif the program is stored in ROM 22. In this case, addition, version-upand the like of an application program become easy. The external storagedevice 25 includes HDD and a CD-ROM (compact-disk—read-only-memory)drive which can read various data such as application programs stored ina CD-ROM. The read data such as an application program is stored in ahard disk loaded in HDD. Installation, version-up and the like of anapplication program become easy. Other types of drives such as a floppydisk drive, a magneto-optical (MO) disk drive may be used as theexternal storage device 25.

[0059] The communications interface 29 is connected to a communicationsnetwork 32 such as the Internet, a local area network (LAN) and atelephone line, and via the communications network 32 to a servercomputer 33. If application programs and data are not stored in a harddisk loaded in HDD 25, these programs and data can be downloaded fromthe server computer 33. In this case, a client such as the encoder 3, 5and home computer 9 transmits a command for downloading an applicationprogram or data to the server computer 33 via the communicationsinterface 29 and communications network 32. Upon reception of thiscommand, the server computer 33 supplies the requested applicationprogram or data to the client via the communications network 32 whichclient receives it via the communications interface 29 and stores it ina hard disk loaded in HDD 25.

[0060] This embodiment may be reduced into practice by a commerciallyavailable personal computer installed with application programs andvarious data realizing the functions of the embodiment. The applicationprograms and various data may be supplied to a user in the form of astorage medium such as a CD-ROM and a floppy disk which the personalcomputer can read. If the personal computer is connected to thecommunications network such as the Internet, a LAN and a telephone line,the application programs and various data may be supplied to thepersonal computer via the communications network.

[0061]FIG. 3 is a diagram illustrating a method of dealing withcommunications errors of MIDI data, indicating a key-on event at a highlevel and a key-off event at a low level by way of example.

[0062] In this example, a key-on event is transmitted at a timing t1 anda key-off event is transmitted at a timing t4. The key-on eventtransmitted at the timing ti may be lost in some case by communicationserrors. In such a case, the home computer 9 on the reception side cannotreceive the key-on event and receives only the key-off event so that acorrect musical performance cannot be reproduced. The reception of onlythe key-off event without the key-on event will not occur according tothe musical performance rule.

[0063] In order to avoid such a case, during the period after thetransmission of the key-on event at the timing t1 and before thetransmission of the key-off event at the timing t4, recovery key data istransmitted periodically at a predetermined time interval, in thisexample, at timings t2 and t3.

[0064] The recovery key-on data is confirmation data which notifies thereception side of a continuation of a key-on state. Even if the key-onevent cannot be received at the timing t1, the key-on event is enabledwhen the recovery key data is received at the timing t2 although thereis some delay from the timing t1. Similarly, even if the key-on eventcannot be received both at the timings t1 and t2, it is enabled at thetiming t3 when the recovery data is received.

[0065] Generally, a musical tone signal attenuates with time. It istherefore preferable to transmit the recovery key data with theinformation of a lowered velocity (sound volume) corresponding to thetime lapse. The velocity information is always contained in the key-onevent and transmitted together with the key-on event. In this example,key-on events (recovery key data) with gradually lowered velocities inthe order of timings t1, t2 and t3 are transmitted.

[0066] A communications error of a key-on event can therefore beremedied by the recovery key data. A recovery method to be used when thekey-off event at the timing t4 is lost will be described next.

[0067] It is possible to transmit key-off recovery data after thekey-off event, similar to the recovery method for the key-on event.However, the time duration of a key-off is much longer than that of akey-on of each key of the keyboard. If the recovery key data istransmitted after the key-off event until the next key-on event occurs,the amount of this recovery key data becomes bulky.

[0068] The recovery key data for the key-on event is transmitted duringthe period after the key-on timing t1 and before the key-off timing t4,and is not transmitted after the key-off timing t4. That the recoverykey data is not transmitted means that a key-off event has alreadyoccurred. Therefore, if the home computer 9 cannot receive the key-offevent at the timing t4 but can detect that the recovery key data is notperiodically transmitted, it is judged that the key state is presently akey-off.

[0069] If the recovery key data cannot be received periodically duringthe key-on, the home computer 9 can judge that there was acommunications error, and enables the key-off so that a falsecontinuation of sound reproduction can be avoided. This judgement ismade by referring to the key-on buffer 21 a shown in FIG. 2, and thedetails thereof will be later described with reference to a flow chart.

[0070] Similar to the key-on and key-off recovery, recovery tonegenerator setting data for recovering lost tone generator setting datacan be obtained by referring to the tone generator setting buffer 21 bshown in FIG. 2.

[0071]FIG. 4 shows the format of a communications packet. Acommunications packet is transmitted from the encoder 3, 5 shown in FIG.1 or received by the personal computer 9 shown in FIG. 1.

[0072] The packet is constituted of a header field 41 and a data field42. The header field 41 contains checksums 43 of two words (one word is16 bits), a data ID 44 of four words, a sequence number 45 of fourwords, time data 46 of four words, and an event data length 47 of twowords.

[0073] The checksums 43 are representative values of all data in theheader field 41 excepting the checksums and in the data field 42. Thetransmitting side calculates these representative values and transmits apacket added with the checksums 43. The receiving side recalculates therepresentative values of data in the packet and checks whether therecalculated representative values are coincide with the transmittedchecksums 43. If coincident, it is judged that there is nocommunications error.

[0074] The data ID 44 is a number identifying the type of the data field42. The numbers “0”, “1” and “2” indicate MIDI data and the number “3”indicates image data. The number “0” indicates real event data (ordinaryMIDI data), the number “1” indicates the recovery key data (FIG. 3), andthe number “2” indicates the recovery tone generator setting data.

[0075] The sequence number 45 is a number assigned to each packet in thesequential order. By checking the sequence number 45, the receiving sidecan recover or reorder the packets even if the order of packets ischanged by communications errors.

[0076] The time data 46 indicates a reproduction time representing 1 msby one bit. Since this data 46 has four words, the time information of100 hours or longer can be given. Using this time information 46 allowsa simultaneous session of a plurality of concert halls. A simultaneousmusical performance can be listened at home by assigning the timeinformation 46 as a musical performance time at each concert hall andproviding synchronization between a plurality of concert halls. Althoughthe time information 46 is preferably an absolute time, it may be arelative time commonly used by all concert halls.

[0077] The event data length 47 indicates the length of data in the datafield 42.

[0078] The data field 42 contains real data 48 which is MIDI data orimage data. The MIDI data contains the recovery key data and recoverytone generator setting data.

[0079] A high communications speed is preferable, for example, 64 Kbits/s (ISDN). The data length of one packet is not limited. It ispreferably about 1 K bytes or 512 bytes from the viewpoint ofcommunications efficiency.

[0080]FIG. 5 is a flow chart illustrating the operation of atransmission process to be executed by the encoder 3.

[0081] At Step SA1, MIDI data is received from the MIDI musicalinstrument 2. At Step SA2, the received data is buffered in RAM 21.

[0082] At Step SA3, the type of an event of the received data ischecked. The type of an event includes a key-on event, a key-off eventand a tone generator setting data event. If the type is key-on, the flowadvances to Step SA6 whereat the key-on event is registered in thekey-on buffer 21 a (FIG. 2) to thereafter follow Step SA7.

[0083] If the type is key-off, the flow advances to Step SA4 whereat thekey-on buffer 21 a is searched. If there is the same key code (soundpitch), the corresponding key-on event is deleted from the key-on buffer21 a to thereafter follow Step SA7.

[0084] If the type is tone generator setting data, the flow advances toStep SA5 whereat the tone generator setting data is registered in thetone generator setting buffer 21 b (FIG. 2) to thereafter follow StepSA7. The tone generator setting data includes program change data,control data, exclusive message data, and the like.

[0085] At Step SA7, the received MIDI data is added with, as shown inFIG. 4, checksums 43, a data ID (No. 0) 44 indicating real event data, asequence number 45, a time data 46 of the timer 24 (FIG. 2) and an eventlength 47. In this case, a plurality of events of the same typegenerated at generally the same time may be collected and configuredinto one packet to be transmitted. After Step SA7, the transmissionprocess is terminated.

[0086] By using the same process, the encoder 4 transmits image data. Inthis case, the data ID 44 is No. 3.

[0087]FIGS. 6A and 6B are flow charts illustrating the interrupt processto be executed by the encoder 3. This interrupt process is performed ata predetermined interval in response to the timing supplied from thetimer 24. For example, the interrupt process is performed at an intervalof 100 to 200 μs.

[0088]FIG. 6A is a flow chart illustrating the transmission process ofrecovery key data.

[0089] At Step SB1, the key-on buffer 21 a (FIG. 2) is searched. At StepSB2, the key-on event data in the key-on buffer 21 a is packeted asshown in FIG. 4 and transmitted as the recovery key data. In this case,a velocity (sound volume) lower than that contained in the key-on eventdata stored in the key-on buffer 21 a is set to the recovery key data,the velocity being set lower by an amount corresponding to the timelapse from the start of the key-on event.

[0090] The data ID 44 in the packet is No. 1 indicating the recovery keydata. The sequence number 45 of this packet is the same as that of thereal event data (FIG. 5). After the recovery key data is transmitted,the process before this interrupt process is resumed.

[0091]FIG. 6B is a flow chart illustrating the transmission process forrecovery tone generator data. A relatively low precision of time isrequired for this transmission process so that the process may beperformed at an interval longer than that of the recovery key datatransmission process (FIG. 6A).

[0092] At Step SC1, the tone generator setting buffer 21 b (FIG. 2) issearched. At Steps SC2, the event data in the tone generator settingbuffer 21 b is packeted as shown in FIG. 4 and transmitted as therecovery tone generator setting information.

[0093] The data ID 44 in the packet is No. 2 indicating the recoverytone generator setting data. The sequence number 45 of this packet isthe same as those of the real event data (FIG. 5) and recovery key data(FIG. 6A). After the recovery tone generator setting data istransmitted, the process before this interrupt process is resumed.

[0094]FIG. 7 is a flow chart illustrating the reception process to beexecuted by the home computer 9.

[0095] At Step SD1, data on the Internet is received. At Step SD2, thechecksums 43 (FIG. 4) in the received packet are checked. If notcoincident, there is a data error or errors.

[0096] At Step SD3 it is checked whether the check result of thechecksums is normal or error. If error, it means that the data in thepacket has an error or errors so that the flow advances to Step SD9 toterminate the process without performing any operation. Not performingany operation and discarding the data having less reliability iseffective because false sound reproduction and setting are notperformed.

[0097] If the checksums are normal, the data in the packet is reliableso that the flow advances to Step SD4 whereat the sequence number 45(FIG. 4) in the packet is checked. In normal communications, thesequence number 45 increases each time a packet is received. However,the order of sequence numbers of received packets changes if there is acommunications error or errors.

[0098] It is checked at Step SD5 whether the received data has thecorrect sequence number 45 and the current time at the home computer 9is the same as or later than the reproduction time 46 (FIG. 4). In thesimultaneous session of a plurality of concert halls, there may be aconcert hall whose time data 46 is still not the reproduction time. Ifthe current time becomes the same as the time data 46, one of the abovecheck conditions is satisfied.

[0099] If the current time is before the reproduction time 46, the flowadvances to Step SD10 whereat the received data is buffered in RAM forthe preparation of a later process at the correct timing. After StepSD10, the reception process is terminated.

[0100] If it is necessary to reproduce the received data, the flowadvances to Step SD6 whereat an event process is performed. The eventprocess is performed for MIDI data and image data, the details thereofbeing later described with reference to the flow chart of FIG. 8.

[0101] At Step SD7, the sequence number is counted up. At Step SD8, itis checked whether there is data buffered in the buffer at Step SD10,the data having the correct sequence number 45, and whether the currenttime at the home computer 9 being the same as or later than thereproduction time 46.

[0102] If there is no data to be reproduced, the reception process isterminated, whereas if there is data to be reproduced, the flow returnsto Step SD6 to perform the above processes at Steps SD6 and SD7. Thereceived data whose order was changed by a communications error can beproperly processed in the above manner. If the buffer has no data to bereproduced, the reception process is terminated.

[0103] If data of a predetermined amount or more is stored in thebuffer, it is judged that the data having the sequence number to be nextprocessed was lost, the process for this data is skipped, and theprocess for the data having the next sequence number is performed.

[0104]FIG. 8 is a flow chart illustrating the detailed operation of theevent process at Sep SD6 of FIG. 7.

[0105] At Step SE1, the number of the data ID 44 (FIG. 4) is checked. Ifthe number is “0”, it means real event data and the flow advances toStep SE2 whereat the type of the event is checked. The type of an eventincludes a key-on event, a key-off event and a tone generator settingdata event.

[0106] If the type of the event is key-on, the flow advances to Step SE3whereas the key-on event is registered in the key-on buffer 21 a (FIG.2) and transferred to the tone generator. Upon reception of the key-onevent, the tone generator performs a process of starting soundreproduction. Thereafter, the process returns to Step SD7 shown in FIG.7.

[0107] If the type of the event is key-off, the flow advances to StepSE4 whereat the key-on buffer 21 is searched. If there is the same keycode (sound pitch), the key-On event in the key-on buffer 21 a isdeleted, and the key-off event is transferred to the tone generator.Upon reception of the key-off event, the tone generator performs aprocess of stopping sound reproduction. Thereafter, the process returnsto Step SD7 shown in FIG. 7.

[0108] If the type of the event is tone generator setting data, the flowadvances to Step SE5 whereat the tone generator setting data isregistered in the tone generator setting buffer 21 b (FIG. 2) andtransferred to the tone generator. Upon reception of the tone generatorsetting data, the tone generator sets a tone color, a sound volume andthe like. Thereafter, the process returns to Step SD7 shown in FIG. 7.

[0109] If the number of the data ID is “1”, it means the received datais recovery key data, and the flow advances to Step SE6 whereat therecovery key data is compared with the corresponding key-on event in thekey-on buffer 21 a and different points between them are used as a newkey-on event which is registered in the key-on buffer 21 a andtransferred to the tone generator. In this manner, a key-on event lostby a communications error can be recovered.

[0110] At Step SE7, a reception of the recovery key data is registered.This registration allows to confirm the key-on state until the recoverykey data is not periodically transmitted after the key-off. If therecovery key data is not periodically transmitted even if a key-on eventis present in the key-on buffer, it means that the key-off event waslost. Thereafter, the process returns to Step SD7 shown in FIG. 7.

[0111] If the number of the data ID is “2”, it means that the receiveddata is tone generator setting data, and the flow advances to Step SE8whereat the recovery tone generator setting data is compared with thecorresponding tone generator setting data in the tone generator settingbuffer 21 b and different points between them are used as a new tonegenerator setting data event which is registered in the tone generatorsetting buffer 21 b and transferred to the tone generator. In thismanner, a tone generator setting data lost by a communications error canbe recovered. Thereafter, the process returns to Step SD7 shown in FIG.7.

[0112] If the number of the data ID is “3”, it means that the receiveddata is image data, and the flow advances to Step SE9 whereat a processof displaying the image data on the display device is performed. Theimage data is processed with a lower priority than the MIDI data.Basically, a display image is processed in the unit of one frame. Inorder to give the MIDI data a priority over the image data, the displayimage may be a still image. Thereafter, the process returns to Step SD7shown in FIG. 7. If the number of the data ID is “4”, it means that thereceived data is sound data, and the flow advances to Step SE10 whereata process of reproducing the sound data is performed.

[0113]FIG. 9 is a flow chart illustrating the operation of an interruptprocess to be executed by the home computer 9. This interrupt process isperformed at a predetermined interval in response to the timing suppliedfrom the timer 24. For example, the interrupt process is performed at aninterval of 100 to 200 μs.

[0114] At Step SF1, the key-on buffer 21 a (FIG. 2) is searched. At StepSF2, of key-on events stored in the key-on buffer 21 a (FIG. 2), thekey-on event to which recovery key data is not transmitted for apredetermined period is deleted, and a key-off event is transferred tothe tone generator. After the key-off event is transferred, the processreturns to the process which was executed before this interrupt process.The predetermined period may be a time duration sufficient for receivingthe recovery key data at least twice.

[0115] With the above recovery process, a false continuation of soundreproduction can be avoided even if a key-off event is lost by acommunications error. The judgement that recovery key data is notreceived for the predetermined period becomes possible because thereception of recovery data is registered at Step SE7 in FIG. 8.

[0116] Since the recovery key data and recovery tone generator settingdata (hereinafter, both the data are collectively called recovery data)are transmitted, a proper recovery is ensured even if there is datachange or data loss.

[0117] Next, a method of alleviating the traffic congestion ofcommunications lines will be described. For the communications ofmusical performance data and recovery data, a fairly large amount ofdata flows on a communications line of the network. The number of usersaccessing the server at the same time for attending the music concert isalso very large.

[0118] Under such circumstances, smooth reproduction of a musicalperformance by the home computer 9 of each user may become unable insome cases. In order to alleviate the congestion of communicationslines, each of a plurality of proxity servers 12 shown in FIG. 1 reducesthe data amount in accordance with the congestion degree ofcommunications lines.

[0119] If the data amount is reduced, the sound quality or image qualityis lowered. In this connection, each proxity server 12 has a datareduction factor, data reduction method, and the number of accessibleusers, specific to the proxity server 12.

[0120] If the number of users accessing the proxity server 12 is small,the proxity server does not reduce the data amount, whereas if thenumber of accessing users becomes large, the proxity server reduces thedata amount and transmits the reduced data.

[0121] The following methods may be used for reducing the data amount.

[0122] (1) Data Separation

[0123] The proxity server receives the musical tone data (MIDI data),image data and sound information (audio data). The image data requiresan image quality not so high as the MIDI data. Therefore, the proxityserver may transmit only the MIDI data and sound information byseparating the received data into MIDI data, sound information and imagedata. Similarly, each of the MIDI data, sound information and image datamay be separated further to transmit only necessary data. The congestedtraffic of communications lines can be alleviated by transmitting onlyimportant data.

[0124] (2) Data Discrimination

[0125] The proxity server may determine the priority order of data andpreferentially transmit important data. Specifically, whilecommunications lines are congested, only important data is transmittedduring this period, and during a later period the data not important istransmitted. Although this method does not reduce the total data amount,the data amount transmitted during each period can be reduced.

[0126] For example, loss of a key-off event is a fatal error as comparedto a loss of a key-on event. Therefore, the key-off event has a higherimportance degree of data. The proxity server may separate the receivedpacket into a key-off event and other data to first transmit the key-offevent and then transmit the other data.

[0127] If a packet contains both a key-on event and a key-off event andthe key-off event separated from the packet is first transmitted andthen the key-on packet is transmitted, this transmission order is notproper. In this case, therefore, both the events are preferably nottransmitted. Similarly, if there is any discrepancy in preferentialtransmission, a necessary countermeasure is required.

[0128] (3) Data Resolution Setting

[0129] In order to reduce the data amount, the proxity server maytransmit data at a low resolution to a user. For example, if the soundvolume increases by one step as the time lapses, the data at a lowresolution increasing the sound volume by two steps is transmitted tohalve the data amount. The resolution may be lowered not only for thesound volume but also for other control data (data supplied fromcontrollers) such as a pitch event and an after-touch event. Differentresolutions may be set in accordance with the type of controller tolower the total resolution of a plurality of control data sets.

[0130] (4) Time Resolution setting

[0131] The recovery data is periodically transmitted. Therefore, theproxity server may prolong the period of transmitting recovery data inorder to reduce the data amount. The transmission rate of image data maybe lowered. For example, eight frames per second may be lowered to fourframes per second to reduce the data amount.

[0132] Next, the proxity server will be described. The structure of theproxity server is similar to that of the computer shown in FIG. 2. Thetone generator 28 and MIDI interface 30 are not necessarily required.

[0133]FIG. 10 shows the structure of a RAM of the proxity server 12shown in FIG. 1.

[0134] RAM of each of a plurality of proxity servers 12 a, 12 b, 12 c, .. . stores the following data.

[0135] (1) The Number of Current Accesses 51

[0136] The number 51 of current accesses is the number of users(communication lines) now accessing the proxity server and changes withtime. The access number is initially set to “0”, increases as the numberof accessing users increases, and decreases as the number of accessingusers decreases.

[0137] (2) Overflow Flag 52

[0138] The overflow flag 51 indicates whether the proxity server is inan overflow state. The overflow flag 52 is initially set to “0” whichmeans no overflow. When the number of users accessing the proxity serverreaches an allowable access number 54 to be later described, theoverflow flag 52 is set to “1”.

[0139] (3) Current Thinning Index 53

[0140] The current thinning index 53 is a currently set thinning index.This index indicates a data reduction (also called data thinninghereinafter) factor and a thinning method. The thinning index 53 isinitially set to “0” which means no data thinning. Table 1 showsexamples of the thinning indices. TABLE 1 Thinning index Thinning method0 All data is transmitted (no thinning) 1 Every third recovery tonegenerator setting data is transmitted 2 Every fourth recovery tonegenerator setting data is transmitted . . . m Every third recovery keydata is transmitted . . . n Resolution of control data is set to 1/2 n +1 Resolution of control data is set to 1/4 . . . z Image data is nottransmitted

[0141] A combination of any ones of the thinning indices may be used asone thinning index.

[0142] (4) Allowable Access Number 54

[0143] The allowable access number 54 is the maximum number of users(communication lines) accessible to the proxity server and may take anydesired value. The allowable access number corresponds to the maximumaccess capacity of the proxity server.

[0144] (5) Allowable Thinning Index 55

[0145] The allowable thinning index 55 is the maximum allowable value ofa thinning index allowed by the proxity server. Preferably, theallowable thinning index is the allowable maximum value of totalthinning by each weighted thinning method. For example, the thinningindex corresponds to a thinning ratio, and the larger the index, thelarger the thinning ratio. Each proxity server can determine itsspecific allowable thinning index in accordance with the access number.

[0146] (6) Table Number 56

[0147] The table number 56 is the number of a table which shows acorrespondence between the access number and the thinning index. FIG. 11shows examples of characteristic curves 60 a, 60 b and 60 c of threetables. Each table shows a correspondence between the access number andthe thinning index. It is preferable that the larger the access number,the larger the access index and the larger the data reduction amount.The characteristic curves 60 a to 60 c are not necessary to take acontinuous value, but may take a discrete value. The value of thethinning index does not always indicate the data reduction amount, sothat it is not necessarily required to take a larger value as the accessnumber increases. These tables are stored in a memory (e.g., RAM).

[0148] A plurality of tables (e.g., three tables 60 a to 60 c) areprepared, and the number of the table most suitable for the proxityserver is used as the table number 56.

[0149] (7) Next Candidate Proxity Server Address 57

[0150] The next candidate proxity server address 57 is an address of thenext candidate proxity server of the proxity server in concern when thelatter overflows. When a user accesses a proxity server and this serveris overflowing, this access is automatically switched to the proxityserver indicated by the next candidate proxity server address.

[0151]FIG. 12 is a flow chart illustrating the operation of the proxityserver when a user accesses it.

[0152] At Step SG1, when an access from a user (client) is detected, theprocesses at Step SG2 and following Steps are performed. By accessingthe proxity server, a user can obtain MIDI data, sound information andimage data.

[0153] At Step SG2, it is checked whether the overflow flag 52 (FIG. 10)is “0” or “1”. If the overflow flag is “1”, it means that the accessnumber is larger than the allowable access number, and the flow advancesto Step SG6.

[0154] At Step SG6, the access is switched to the next candidate proxityserver indicated by the next candidate proxity server address 57 (FIG.10). Namely, the user access is automatically switched to the nextproxity server. As a result, the user accesses this next proxity server.If the next candidate proxity server is also overflowing, the secondnext proxity server is accessed. In this manner, if the accessed proxityserver is congested, the access is automatically switched to the proxityserver not congested. After the access is switched to another proxityserver, the first accessed proxity server terminates its operation.

[0155] If it is judged at Step SG2 that the overflow flag is “0”, itmeans that the access number of this proxity server is smaller than theallowable access number, and the flow advances to Step SG3.

[0156] At Step SG3, the current access number 51 (FIG. 10) isincremented by 1. The access number 51 is the number of users currentlyaccessing the proxity server. Each time an access from a user ispermitted, the proxity server increments the access number 51 by 1.

[0157] Next, with reference to the table (FIG. 11) indicated by thetable number 56 (FIG. 10), the thinning index corresponding to thecurrent access number 51 is obtained and written in the memory as thecurrent thinning index 53. If the obtained thinning index is the same asthe previously used one, the write operation may be omitted. As theaccess number becomes large, the thinning index having a large thinningratio is selected.

[0158] At Step SG4, it is checked whether the current access number 51is same as the allowable access number 54 (FIG. 10). If same, the flowadvances to Step SG5 whereat the overflow flag 52 is set to “1” so asnot to increase the access number more than the allowable access number.If not same, the overflow flag is maintained “0”. Thereafter, the aboveoperation by the proxity server is terminated.

[0159]FIG. 13 is a flow chart illustrating the operation of the proxityserver when a user releases its access.

[0160] At Step SH1, when an access release by a user (client) isdetected, the processes at Step SH2 and following Steps are performed.

[0161] At Step SH2, the current access number 51 (FIG. 10) isdecremented by 1. Each time an access release by a user is detected, theproxity server decrements the access number 51 by 1.

[0162] Next, with reference to the table (FIG. 11) indicated by thetable number 56 (FIG. 10), the thinning index corresponding to thecurrent access number 51 is obtained and written in the memory as thecurrent thinning index 53. If the obtained thinning index is the same asthe previously used one, the write operation may be omitted. As theaccess number becomes small, the thinning index having a small thinningratio is selected.

[0163] At Step SH3, it is checked whether the overflow flag 52 (FIG. 10)is “1”. If the overflow flag is “1”, the flow advances to Step SH4 toset the overflow flag to “0” so as to permit a new access. If theoverflow flag is “0”, it is maintained “0”. Thereafter, the aboveoperation by the proxity server is terminated.

[0164] The overflow flag may not be checked at Step SH3, and theoverflow flag is set to “1” irrespective of the overflow value of “1” or“0”. Also in this case, the operation equivalent to the above can berealized.

[0165]FIG. 14 is a flow chart illustrating the operation of the proxityserver when it receives data from the main server.

[0166] At Step SI1, the proxity server receives data in the packet formfrom the main server 7 (FIG. 1). The data includes musical tone data(inclusive of recovery data), sound information and image data. Theproxity server receives data not thinned. A plurality of proxity serversall receive the same data.

[0167] At Step SI2, in accordance with the current thinning index 53(FIG. 10), a thinning method (state) is determined. For example, if thethinning index is “0”, the data is not thinned.

[0168] At Step SI3, in accordance with the determined thinning method,the predetermined data is deleted from the data field 42 (FIG. 4) of thereceived packet.

[0169] At Step SI4, the checksums 43, data length 47 and the like in thepacket header field 41 (FIG. 4) are renewed to match the data whosepredetermined data was deleted.

[0170] At Step SI5, the renewed packet is transmitted to the WWW server8 (FIG. 1). The WWW server 8 receives the predetermined thinned data.All the proxity servers receiving the same data from the main server 7may perform different thinning operations to transfer data to the WWWserver. The above processes by the proxity server are thereafterterminated.

[0171]FIG. 15 is a flow chart illustrating the operation of the proxityserver when it thins the recovery data. When recovery data is received,a recover_time register is reset to “0”, and thereafter it isincremented by 1 each time a predetermined time lapses. Therecover_timer register shows a lapse time after the previous recoverydata is received.

[0172] At Step SJ1, it is checked whether the packet received from themain server 7 is recovery data. This check is performed by referring tothe data ID 44 (FIG. 4). If the value of the data ID is “1” or “2”, thereceived packet is recovery data. This flow chart illustrates theoperation of thinning recovery data, and if data other than the recoverydata is received, this process is terminated immediately. When therecovery data is received, the flow advances to Step SJ2.

[0173] At Step SJ2, it is checked whether the value of the recover_timerregister is larger than the time designated by the thinning index. Therecover_timer register shows a lapse time after the previous recoverydata is received. The time designated by the thinning index correspondsto the period of transmitting the recovery data.

[0174] If the value of the recover_timer register is larger than thetime designated by the thinning index, the flow advances to Step SJ3.

[0175] At Step SJ3, the received packet is transferred to the WWW server8. At Step SJ4, the recover_timer register is set to “0” to terminatethe above processes. The recover_timer register is counted up at apredetermined time interval by an interrupt process. This interruptprocess is enabled at the predetermined time interval by the timer 24shown in FIG. 2.

[0176] If it is judged at Step SJ2 that the value of the recover_timeris not larger than the time designated by the thinning index, it meansthat the predetermined time does not still lapse, and the flow advancesto Step SJ5.

[0177] At Step SJ5, all the data field of the received packet isdiscarded and only the header field is left. At Step SJ6, the packetconstituted of only the header field is transferred to the WWW server 8to thereafter terminate the above processes.

[0178] In the above operation, the packet with only the header field istransferred. Instead, the packet itself may not be transferred in orderto further reduce the data amount. In use. this case, however, it isnecessary to judge whether the packet is deleted by thinning or it islost by a communications error. If the packet is lost by acommunications error, it is necessary to recover it, whereas if it isdeleted by thinning, it is unnecessary to recover it.

[0179] Instead of counting up the value of the recover_timer register bythe interrupt process, the number of receptions of recovery data fromthe main server may be counted. For example, of three receptions ofrecovery data from the main server, the recovery data received at thefirst and second times is deleted and the packets with only the headerfield are transferred, and for the recovery data received at the thirdtime, the packet with both the header and data fields is transferred.With this process, it is not necessary to count up the value of therecover_timer register by the interrupt process.

[0180] In order to simplify the process, the sequence number 45 and timedata 46 in the packet may not be renewed. Conversely, if the dataquality is to be improved, the sequence number 45 and time data 46 maybe renewed. This additional data renewal can recover more reliably thedata lost by communication errors such as data loss and data change.

[0181]FIG. 16 is a flow chart illustrating the operation of the proxityserver when it transmits a key-off event with a priority over the key-onevent.

[0182] At Step SK1, the key-off event data is derived from the packetreceived from the main server, and the flow advances to Step SK2. If thepacket does not contain key-off event data, the whole received packet istransferred to the WWW server 8.

[0183] At Step SK2, a new packet having the data field containing onlythe derived key-off event data is generated.

[0184] At Step SK3, the newly generated packet is transferred to the WWWserver 8.

[0185] At Step SK4, the remaining packet with the key-off event databeing deleted is transferred to the WWW server 8 to thereafter terminatethe above processes. In the above processes, the data in the packet isseparated into the key-off event data and other data, first at Step SK3the key-off event data is preferentially transferred, and then at StepSK4 the other data is transferred.

[0186] As the transfer timing at Step SK4 is delayed from the transfertiming at Step SK3, data can be transferred in a dispersed manner, thetraffic congestion can be alleviated as compared to the case where allthe data is transferred at the same time.

[0187]FIG. 17 is a flow chart illustrating the operation of the proxityserver when it transfers data by deleting the image data.

[0188] At Step SL1, it is checked whether the packet received from themain server is image data. This check is realized by referring to thedata ID 44 (FIG. 4). If the value of the data ID is “3”, the receivedpacket is image data. This flow chart illustrates the operation ofdeleting image data, and if data other than the image data is received,this process is terminated immediately. When the image data is received,the flow advances to Step SL2.

[0189] At Step SL2, the data field of the received packet is deleted andonly the header field is left. At Step SL3, a packet with only theheader field is transferred to the WWW server 8 to thereafter terminatethe above processes.

[0190] Also in this case, instead of transferring the packet with onlythe header field, the packet itself may not be transferred in order tofurther reduce the data amount.

[0191]FIG. 18 is a flow chart illustrating the operation of the proxityserver when it transfers data by lowering the resolution.

[0192] At Step SM1, data to be thinned is derived from the packetreceived from the main server, and the flow advances to Step SM2. Thedata to be thinned includes control data such as volume data, pitchevent data and after-touch event data. If the packet does not containdata to be thinned, the whole received packet is transferred to the WWWserver 8.

[0193] At Step SM2, the data is converted into values corresponding to adesignated resolution. For example, if a resolution is ¼, the data setsof the same type in the packet are all multiplied by ¼ and the decimalfractions are cut off.

[0194] At Step SM3, of the data sets having the same converted value,only one data set is left in the packet and all other data sets aredeleted. The resultant packet is transferred to the WWW server.

[0195] The data to be thinned may be subjected to modulo calculation,and only the data sets with the calculation result of “0” may be left todelete all other data sets.

[0196] A plurality type of data sets to be thinned may be provided witheach type being assigned a different resolution.

[0197] In the embodiment described above, musical performanceinformation (MIDI data), sound data (audio data) and musical performanceimage (image data) in a concert hall can be supplied to a number ofusers by using the Internet. A user can obtain MIDI data and image datain real time at home without going to the remote concert hall.

[0198] If the encoder at each of a plurality of concert halls adds timedata to MIDI data and the like, a simultaneous session by a plurality ofconcert halls becomes possible.

[0199] Each of a plurality of proxity servers reduces the data amount inaccordance with the number of accesses to the proxity server, so thatthe traffic congestion can be alleviated. If the number of proxityservers is increased, the traffic congestion can be alleviated withoutthinning the data. If the data is thinned, the traffic congestion can bealleviated even if the number of proxity servers is small.

[0200] If the data amount is reduced, the sound quality and imagequality are degraded. In this connection, each proxity server can selecta data thinning ratio and method most suitable for the proxity server,and can set the desired number of accessible users.

[0201] The proxity server transmits information on the data thinningratio and method to a user so that this information can be displayed onthe screen of the display device of a home computer. For example, “Now,with lowered sound quality”, “Now, with only musical tone data” or thelike can be displayed. This display is preferably made when a useraccesses the proxity server. A user can access a desired proxity serverby referring to this display.

[0202] A mirror server is also used in the Internet. However, thismirror server is different from the proxity server of the embodiment inthat all mirror servers perform the same operation and supply the samedata.

[0203] The embodiment is not limited only to the Internet, but othercommunication systems may also be used, for example, digital serialcommunications of IEEE1394 specifications, communication satellites andthe like.

[0204] The present invention has been described in connection with thepreferred embodiments. The invention is not limited only to the aboveembodiments. It is apparent that various modifications, improvements,combinations, and the like can be made by those skilled in the art.

What is claimed is:
 1. A musical tone data communications system,comprising: input means for inputting music data including MIDI data;packet means for packeting the music data; and transmitting means fortransmitting the packeted music data over a communication network.
 2. Amusical tone data communication system according to claim 1, furthercomprising: music data generating means for generating the music datarepresenting a musical performance by a player.
 3. A musical tone datacommunication system according to claim 1, further comprising: receivingmeans for receiving the packeted music data on the communication networktransmitted by said transmitting means.
 4. A musical tone datacommunication system according to claim 3, further comprising: unpacketmeans for returning the packeted music data to the music data; andsupply means for supplying the music data returned by said unpacketmeans to tone signal generator means.
 5. A musical tone datacommunication system, comprising: receiving means for receiving packetedmusic data including MIDI data on a communication network; unpacketmeans for returning the packeted music data received by receiving meansto the music data; and supply means for supplying the music datareturned by said unpacket means to tone signal generator means.
 6. Amusical tone data communication system according to claim 5, whereinsaid tone signal generator means generates a tone signal in accordancewith the music data supplied from said supply means.
 7. A musical tonedata communication system, comprising: music data transmitting means fortransmitting music data including MIDI data to a communication network;and recovery data transmitting means for transmitting recovery data tothe communication network after said music data transmitting means hastransmitted the music data, the recovery data indicating that aninstruction represented by the music data has not yet been finished. 8.A musical tone data communication system according to claim 7, whereinsaid recovery data transmitting means periodically transmits therecovery data.
 9. A musical tone data communication system according toclaim 7, wherein said music data transmitting means transmits a key-onevent data corresponding to a start of production of a tonecorresponding to said music data at a first timing and a key-off eventdata corresponding to a termination of production of said tone at asecond timing, and said recovery data transmitting means transmits therecovery data during a period after the first timing and before thesecond timing.
 10. A music data communication system according to claim7, further comprising: receiving means for receiving the music datatransmitted by said music data transmitting means and the recovery datatransmitted by said recovery data transmitting means; and supply meansfor supplying a tone parameter corresponding to the MIDI data to tonesignal generator means when the receiving means receives the music data,and for supplying a tone parameter corresponding to the recovery data tosaid tone signal generator means when the receiving means receives therecovery data.
 11. A data communications system comprising: receivingmeans for receiving data, said receiving means including a plurality ofreceivers; transmitting means; and access checking means for checkingthe number of said receivers which access said transmitting mean, saidtransmitting means reducing the amount of data received by saidreceiving means in accordance with the access number and transmittingthe reduced data to said receiving means.
 12. A data communicationssystem according to claim 11, wherein said transmitting means can reducethe amount of data through an operation of data separation, datadiscrimination, data resolution setting, time resolution setting, or acombination thereof.
 13. A communication system having a plurality ofcommunications apparatuses, each having receiving means and transmittingmeans, wherein: said receiving means of the plurality of communicationsapparatuses receive the same data including MIDI data; said transmittingmeans of the plurality of communications apparatuses can reduce theamount of data received by said receiving means and can transmit thereduced data; and the data reduction by transmitting means of one of theplurality of communications apparatuses is done differently from that bytransmitting means of the plurality of communications apparatuses.
 14. Acommunication system according to claim 13, further comprising: accesschecking means provided at each of the plurality of communicationsapparatuses for checking the number of receivers of receiving meanswhich access transmitting means of the plurality of communicationapparatus, wherein said transmitting means apparatuses reduces theamount of data received by said receiving means in accordance with theaccess number and transmitting the reduced data to said receiving means.15. A communications system according to claim 13, wherein saidtransmitting means of each of the plurality of communicationsapparatuses can also transmit information on data reduction.
 16. Acommunications system according to claim 13, wherein a receiver at eachof the plurality of communications apparatuses can make a new access totransmitting means of said one of the plurality of communicationapparatuses according to the number of receivers which are accessingsaid transmitting means.
 17. A music data communications systemaccording to claim 1, wherein the music data further includes sound datarepresenting a sound.
 18. A music data communications system accordingto claim 17, wherein said sound data includes voice data representing avoice.
 19. A music data communications system according to claim 1,wherein the music data further includes image data representing animage.
 20. A music data communications system according to claim 19,wherein said image data represents at least one of a moving picture, astill picture or a combination thereof.
 21. A music data communicationssystem according to claim 1, wherein said transmitting means transmitsthe packeted music data essentially in real time.
 22. A music datacommunications system according to claim 1, wherein said transmittingmeans transmits the packeted music data in parallel to a plurality ofreceivers.
 23. A music data communications system according to claim 22,said receiver is a home computer.
 24. A music data communications systemaccording to claim 5, wherein the music data further includes sound datarepresenting a sound.
 25. A music data communications system accordingto claim 24, wherein said sound data includes voice data representing avoice.
 26. A music data communications system according to claim 5,wherein the music data further includes image data representing animage.
 27. A music data communications system according to claim 26,wherein said image data represents at least one of a moving picture, astill picture or a combination thereof.
 28. A music data communicationssystem according to claim 5, wherein said output means outputs the musicdata essentially in real time.
 29. A music data communications systemaccording to claim 7, wherein the music data further includes sound datarepresenting a sound.
 30. A music data communications system accordingto claim 29, wherein said music data includes voice data representing avoice.
 31. A music data communications system according to claim 7,wherein the music data further includes image data representing animage.
 32. A music data communications system according to claim 31,wherein said image data represents at least one of a moving picture, astill picture or a combination thereof.
 33. A data communications systemaccording to claim 11, wherein the data further includes sound datarepresenting a sound.
 34. A data communications system according toclaim 33, wherein said sound data includes voice data representing avoice.
 35. A data communications system according to claim 7, whereinthe data further includes image data representing an image.
 36. A datacommunications system according to claim 35, wherein said image datarepresents at least one of a moving picture, a still picture or acombination thereof.
 37. A data communications system according to claim7, wherein said data include at least two among MIDI data, image data,sound data and recovery data, and said transmitting means reduces dataamount of at least one of said at least two.
 38. A communication systemaccording to claim 13, wherein said same data include at least two amongMIDI data, image data, sound data and recovery data, and saidtransmitting means reduces data amount of at least one of said at leasttwo, the kind of data reduced by transmitting means of one of theplurality of communications apparatuses being different from thatreduced by transmitting means of another of the plurality ofcommunications apparatuses.
 39. A communication system according toclaim 15, wherein said information represents what data is reduced. 40.A communication system according to claim 15, wherein said informationrepresents a fact that data have been reduced.
 41. A communicationsystem according to claim 13, wherein a receiver at each of theplurality of communications apparatuses can make a new access totransmitting means of another of the plurality of communicationsapparatuses according to the number of receivers which are accessingtransmitting means of said one of the plurality of communicationsapparatuses.
 42. A musical tone data communications system, comprising:inputer for inputting music data including MIDI data; packeter forpacketing the music data; and transmitter for transmitting the packetedmusic data over a communication network.
 43. A musical tone datacommunication system, comprising: receiver for receiving packeted musicdata including MIDI data on a communication network; unpacketer forreturning the packeted music data received by receiver to the musicdata; and supplier for supplying the music data returned by saidunpacketer to tone generator.
 44. A musical tone data communicationsystem, comprising: music data transmitter for transmitting music dataincluding MIDI data to a communication network; and recovery datatransmitter for transmitting recovery data to the communication networkafter said music data transmitter has transmitted the music data, therecovery data indicating that an instruction represented by the musicdata has not yet been finished.
 45. A data communications systemcomprising: a plurality of receivers for receiving data, transmitter;and access checker for checking the number of said receivers whichaccess said transmitter, said transmitter reducing the amount of datareceived by said receivers in accordance with the access number andtransmitting the reduced data to said receivers.
 46. A communicationsystem having a plurality of communications apparatuses, each havingreceiver and transmitter, wherein: said receiver of the plurality ofcommunications apparatuses receive the same data including MIDI data;said transmitter of the plurality of communications apparatuses canreduce the amount of data received by said receiver and can transmit thereduced data; and the data reduction by transmitter of one of theplurality of communications apparatuses is done differently from that bytransmitter of the plurality of communications apparatuses.
 47. Amusical tone data communications method comprising the steps of: (a)inputting music data including MIDI data; (b) packeting the music data;and (c) transmitting the packeted music data over a communicationnetwork.
 48. A musical tone data communication method comprising thesteps of: (a) receiving packeted music data including MIDI data on acommunication network; (b) unpacketing and returning the packeted musicdata to the music data; and (c) supplying the returned music data totone generator.
 49. A musical tone data communication method comprisingthe steps of: (a) transmitting music data including MIDI data to aCommunication network; and (b) transmitting recovery data to thecommunication network after the music data is transmitted, the recoverydata indicating that an instruction represented by the music data hasnot yet been finished.
 50. A data communications method comprising thesteps of: (a) receiving data; (b) checking the number of communicationslines accessed externally; and (c) reducing the amount of received datain accordance with the access number, and transmitting the reduced datato the communications lines accessed externally.
 51. A datacommunication method comprising the steps of: (a) receiving the samedata including MIDI data at a plurality of communications apparatuses;and (b) reducing different data in the same data received at one andanother of the plurality of communications apparatuses and transmittingthe resultant data.
 52. A data communication method comprising the stepsof: (a) receiving the same data including MIDI data at a plurality ofcommunications apparatuses; (b) checking the number of communicationslines accessed externally at each of the plurality of communicationsapparatuses; and (c) reducing the amount of data to be received at eachof the plurality of communications lines in accordance with the accessnumber, and transmitting the reduced data to the communications linesaccessed externally, wherein different data in the same data received atone and another of the plurality of communications apparatuses isreduced and the resultant data is transmitted.
 53. A medium storing acomputer executable program, the program comprising the steps of: (a)inputting music data including MIDI data; (b) packeting the music data;and (c) transmitting the packeted music data over a communicationnetwork.
 54. A medium storing a computer executable program, the programcomprising the steps of: (a) receiving packeted music data includingMIDI data on a communication network; (b) unpacketing and returning thepacketed music data to the music data; and (c) supplying the returnedmusic data to tone generator.
 55. A medium storing a computer executableprogram, the program comprising the steps of: (a) transmitting musicdata including MIDI data to a communication network; and (b)transmitting recovery data to the communication network after the musicdata is transmitted, the recovery data indicating that an instructionrepresented by the music data has not yet been finished.
 56. A mediumstoring a computer executable program, the program comprising the stepsof: (a) receiving data; (b) checking the number of communications linesaccessed externally; and (c) reducing the amount of received data inaccordance with the access number, and transmitting the reduced data tothe communications lines accessed externally.
 57. A medium storing acomputer executable program, the program comprising the steps of: (a)receiving the same data including MIDI data at a plurality ofcommunications apparatuses; and (b) reducing different data in the samedata received at one and another of the plurality of communicationsapparatuses and transmitting the resultant data.
 58. A medium storing acomputer executable program, the program comprising the steps of: (a)receiving the same data including MIDI data at a plurality ofcommunications apparatuses; (b) checking the number of communicationslines accessed externally at each of the plurality of communicationsapparatuses; and (c) reducing the amount of data to be received at eachof the plurality of communications lines in accordance with the accessnumber, and transmitting the reduced data to the communications linesaccessed externally, wherein different data in the same data received atone and another of the plurality of communications apparatuses isreduced and the resultant data is transmitted.